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FOREWORD 


1 .  This  tailoring  document  defines  the  Government’s  requirements  and  expectations  for 
contractor  performance  in  defense  system  acquisitions  and  technology  developments. 

2.  This  new-issue  SMC  tailoring  comprises  the  text  of  The  Aerospace  Corporation  report 
number  TOR-2015-01949,  entitled  Tailoring  of  IEEE  15288.1:  Specialty  Engineering 
Supplement. 

3.  Beneficial  comments  (recommendations,  changes,  additions,  deletions,  etc.)  and  any 
pertinent  data  that  may  be  of  use  in  improving  this  document  should  be  forwarded  to  the 
following  addressee  using  the  Standardization  Document  Improvement  Proposal  appearing  at  the 
end  of  this  document  or  by  letter: 


Division  Chief,  SMC/ENE 
SPACE  AND  MISSILE  SYSTEMS  CENTER 
Air  Force  Space  Command 
483  N.  Aviation  Blvd. 

El  Segundo,  CA  90245 

4.  This  tailoring  document  has  been  approved  for  use  on  all  Space  and  Missile 
Systems  Center/Air  Force  Program  Executive  Office  -  Space  development,  acquisition, 
and  sustainment  contracts. 


Tailoring  of  IEEE  15288.1:  Specialty  Engineering  Supplement. 

1 .  Intent  of  this  Tailoring  Document 

This  tailoring  document  is  a  domain-area  supplement  to  the  industry-consensus  systems  engineering 
standard,  adding  specialty  engineering  requirements  that  have  been  historically  deemed  valuable  to 
mission  assurance/success  of  high-reliability  space  systems. 

This  tailoring  document  supplements  IEEE  15288.1-2015  Annex  E,  which  extends  the  guidance  of 
1SO/1EC/1EEE  15288:2105  Annex  E.4,  Process  view  for  specialty  engineering .  This  document  identifies 
the  specialty  engineering  disciplines1,2  which  are  critical  to  high-reliability  space  systems  for  optimizing 
total  system  performance  and  total  ownership  costs,  while  ensuring  that  the  system  is  designed,  operated, 
and  maintained  to  effectively  provide  the  user  with  the  ability  to  complete  their  mission. 

2.  Context 

2.1  ISO-IEC-IEEE-1 5288:  2015, 

Systems  and  Software  Engineering  —  System  life  cycle  processes 

1SO-1EC-1EEE  15288  is  the  DOD-adopted  standard  for  systems  engineering.1 2 3 

2.2.  IEEE-15288.1:  2015, 

Standard  for  Application  of  Systems  Engineering  on  Defense  Programs 

IEEE  15288.1  is  an  addendum  to  ISO-15288  for  application  of  systems  engineering  on  defense 
programs  that  was  developed  by  a  joint  services  working  group  under  the  auspices  of  the 
Defense  Standarization  Council.  The  Joint  DOD  Systems  Engineering  working  group  was  led 
by  industry  and  the  SMC  Chief  Systems  Engineer  on  behalf  of  DOD.  This  systems  engineering 
standard  was  developed  in  conjunction  with  IEEE  15288.2,  Technical  Reviews  and  Audits  on 
Defense  Programs,  and  coordinated  with  SAE  International’s  EIA-649-1,  Configuration 
Management  for  Defense  Programs.  IEEE  15288.1  was  formalized  as  a  standard  by  the  IEEE’s 
Computer  Society.  The  balloting  involved  a  broad  range  of  government  and  industry  members 

and  was  nearly  unanimous.  IEEE  15288. 1  has  been  adopted  by  DOD  for  use  on  contracts. 

2.3.  SMC-S-001  (201 3),  Systems  Engineering  Products  and  Requirements 

SMC-S-001  is  the  systems  engineering  document  that  was  used  by  SMC  since  2008.  It  were 
used  as  the  basis  for  development  of  IEEE  15288.1  since  it  was  the  only  systems  engineering 
standard  found  to  be  suitable  for  use  on  DOD  contracts.  This  standard  is  the  only  standard  that 
integrates  systems  and  specialty  engineering  as  it  relates  to  high-reliability  space  systems  in  a 
contractually  compliant  manner.  The  specialty  engineering  requirements  in  this  document 
derive,  verbatim,  from  SMC-S-001.  SMC-S-001  will  be  superseded  in  the  SMC  Compliance 
Standards  list  by  1SO-1EC-1EEE  15288,  IEEE  15288.1,  and  this  supplement. 


1  SMC  Standard  #  SMC-S-001  (2013),  Systems  Engineering,  Section  4.3;  a  republication  of  The  Aerospace  Corporation  report  # 
TR-20 13-00001,  Systems  Engineering  Requirements  and  Products. 

2  USAF  Space  and  Missile  Systems  Center.  SMC  Systems  Engineering.  Specialty  Engineering  Disciplines.  Volume  2,  1st  edition. 

3  October  2011. 

3  Notice  -  Adoption,  Tier  2.  http://quicksearch.dla.mil/qsDocDetails.aspx7ident_numbeF213120 
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3.  Tailoring  of  IEEE  15288.1 

3.1.  General  IEEE  15288.1  Tailoring  Instructions 

The  requirements  in  this  document  shall  be  used  in  conjunction  with  1SO-1EC-1EEE  15288  and  IEEE 

15288.1  on  contract. 

The  requirements  of  this  document  shall  prevail  in  the  event  of  conflict  between  this  document  and 
ISO-1EC-1EEE  15288  or  IEEE  15288.1. 

Annex  E.4  from  1SO-1EC-1EEE-15288:2015  shall  be  normative  (requirements)  rather  than 
informative  (guidance). 

This  document,  Tailoring  of  IEEE  15288.1:  Specialty  Engineering,  shall  replace  IEEE  15288.1-2015 
Annex  E  in  its  entirety  and  shall  be: 

1 .  Normative  (requirements  rather  than  informative  guidance), 

2.  Tailored  appropriately  for  specific  acquisition/contract  considerations,  and 

3.  Implemented  as  part  of  the  performance  of  IEEE  15288.1  Task  6.4.1. 3,  Business  or  Mission 
Analysis  Process 

NOTE:  Acquirers  should  utilize  their  organizational  or  domain  area  compliance  standards  list  (or 
other  related  sources)  and  invoke  the  appropriate  standards  for  the  performance  of  detailed 
specialty  engineering  activities. 

3.2.  Specific  IEEE  15288.1  Tailoring  Language 

3.2.1  Specialty  Engineering  Analysis  and  Control 

The  contractor  shall,  for  each  specialty  area  listed  below: 

a.  Ensure  that  the  following  specialty  functions  and  disciplines  are  incorporated  into  the  systems 
engineering  process. 

b.  Establish  a  documented  valid/approved  process  (including  but  not  limited  to  applicable 
corporate  process,  military  standards,  military  handbooks,  NSS/industry  standard  processes) 
that  is  comprehensive  and  responsive  to  the  system/end-user  requirements  for  each  specialty 
engineering  area  being  integrated  into  the  systems  engineering  effort. 

c.  Include  specialty  engineering  requirements  in  the  requirements  analysis,  functional 
analysis/allocation,  synthesis,  and  systems  analysis  and  control. 

d.  Include  their  impact  in  system  life  cycle  cost  estimates  as  well  as  in  total  system 
performance/reliability  assessments. 

e.  Document  specific  specialty  engineering  products/outputs  in  the  SEMP. 

3.2.2  Parts,  Materials,  and  Processes  (PMP) 

NOTE:  Address  as  part  of  Project  Planning  Outputs  -6.3.1 .4 
a.  Detailed  environmental  parameters  are  defined/derived  that  impact  parts  performance. 
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b.  Parts/materials  engineering/design  requirements  are  allocated,  baselined,  and  traced  to 
system-level  performance  requirements,  including  risk  assessments. 

c.  Functional  parameters  are  baselined  and  captured  in  detailed  technicaPprocurement 
specifications. 

d.  Technology  development  plans  are  executed  and  technology  readiness  levels  demonstrate 
products/technology  suitable  for  system  application  and  support  program  development 
schedules. 

e.  Qualified  sources  of  supply  and  industrial  base  assessment  are  addressed. 

f.  Space  systems  radiation-hardening  design  solutions  are  established. 

3.2.3  Structures 

NOTE:  Address  as  part  of  Project  Planning  Outputs  -6.3.1 .4 

a.  Detailed  performance  and  technical  requirements  for  each  structural  system,  subsystem,  and 
component  are  defined,  allocated,  and  traced  to  system  requirements. 

b.  Structural  design  specifications  comply  with  requirements  and  NSS  industry  practice. 

c.  Verification  methods  for  each  structural  requirement  are  defined. 

d.  Structural  requirements  correlation  with  military  and  other  government  documents,  including 
standards,  specifications,  handbooks,  guidelines,  and  Commander’s  policies,  are  presented. 

e.  Technical  risk  mitigation  approaches  are  defined. 

f.  Trade  studies  and  detailed  analyses  support  structural  design  solutions. 

g.  Analysis  tools  and  techniques  are  consistent  with  NSS  industry  practice. 

h.  Design  qualification  methods  adequately  define  approach  to  demonstrate  structural  adequacy. 

i.  Quality  assurance  methodology  ensures  delivery  of  high-quality  product. 

3.2.4  Manufacturing 

NOTE:  Address  as  part  of  Project  Planning  Outputs  -6.3.1 .4 

a.  Producibility  engineering  principles  and  practices  are  integrated  into  the  design  process. 

b.  Manufacturing  methods  and  processes  required  to  build  the  design  are  qualified  and 
demonstrated  to  meet  system  performance  requirements  and  reliability. 

c.  Manufacturing  analyses  include  producibility  analyses  and  manufacturing  and  production 
inputs  to  system  effectiveness,  tradeoff  studies,  and  life  cycle  cost  analyses. 

d.  Alternative  designs  and  capabilities  of  manufacturing  are  evaluated. 
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e.  Long-lead-time  items,  material  source  limitations,  availability  of  materials  and  manufacturing 
resources,  and  production  cost  are  identified,  assessed,  and  documented. 

f.  Manufacturing-critical  characteristics  of  people,  product,  and  process  solutions  and  their  risks 
are  identified. 

g.  Tooling  and  test  equipment  strategies  and  requirements  are  defined. 

h.  Manufacturing  and  producibility  requirements  and  constraints  are  defined. 

i.  Items  are  producible  and  stable  manufacturing  processes  are  in  place  to  reduce  risk, 
manufacturing  cost,  lead  time,  and  cycle  time,  and  to  minimize  use  of  strategic  and  critical 
materials. 

j.  As  part  of  system  design,  manufacturing  methods,  processes,  and  process  controls  have  been 
defined,  evaluated,  and  selected,  based  on  total  system  cost,  schedule,  performance,  and  risk. 

k.  Product  design  has  stabilized,  the  manufacturing  processes  and  process  controls  have  been 
proven,  and  production  facilities,  equipment,  capability,  and  capacity  are  in  place  (or  are 
about  to  be  established)  to  support  the  approved  schedule. 

3.2.5  Quality  Assurance 

NOTE:  Comprehensively  addressed  as  part  of: 

•  Quality  Management  Process  -  6.2.5  and 
Quality  Assurance  process  -  6.3.8 

3.2.6  Test 

NOTE:  Comprehensively  addressed  as  part  of: 

•  Project  Assessment  and  Control  -  6. 3. 2. 3  (process)  and  6. 3. 2.4  (outputs); 

•  Decision  Management  Process  Outputs  -  6. 3. 3. 4; 

•  Risk  Management  Process  -  6.3.4; 

•  Configuration  management  -  6. 3. 5.4  c.2  (process)  and  6. 3. 7. 4  c.l  (outputs); 

•  Measurement  -  6.3.7. 1  (process)  and  6. 3. 7.4  c.l  (outputs); 

•  System  Requirements  Definition  process  -  6.4.3.4; 

•  Architecture  Definition  Process  -  6.4.4. 1 ; 

•  Design  Definition  Process  -  6.4.5. 1 ; 

•  Verification  Process  Output  -  6. 4.9. 4; 

•  Transition  Process  Output  -6.4.10.4; 

•  Operation  Process  Output  -  6.4. 12.4;  and 

•  Data  Requirements  -  5.3 

3.2.7  Survivability 

NOTE:  Address  as  part  of  Project  Planning  Outputs  -6.3.1 .4 
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a.  System-level  survivability  requirements  are  defined,  allocated,  baselined,  and  traced  to  the 
system-level  requirements. 

b.  System  survivability  attributes  and  mission  objectives  evolved  into  a  set  of  system-level 
survivability  requirements. 

c.  An  approach  for  verification  of  system-level  survivability/operability  requirements  is 
identified. 

d.  Test  facilities  capable  of  simulating  threat  environments  are  identified. 

e.  Threat  assessments  and  analysis  are  conducted,  defining  categories  of  the  expected  threats 
(i.e.,  nuclear,  biological,  terrorism,  etc.)  and  their  likelihood  of  occurrence. 

f.  Threats  and  mitigation  strategies  are  defined. 

g.  Nuclear  and  other  threats  are  translated  into  system  environments  and  modeled. 

h.  System/threat  interaction  analysis  is  performed. 

i.  Hardness  levels  and  definition  of  hardness  margins  and  design  criteria  are  identified. 

3.2.8  Environmental,  Safety,  and  Occupational  Health  (ESOH) 

NOTE:  address  as  part  of  Systems  Analysis  Outputs  -  6. 4. 6. 4 

a.  System-level  ESOH  requirements  are  defined,  allocated,  baselined,  and  traced  to  the  system- 
level  requirements: 

( 1 )  Hazards  are  identified. 

( 1 )  Hazardous  materials  are  analyzed,  including  handling  and  disposal. 

(2)  Mitigation  decisions  are  evaluated. 

(3)  Residual  risk  acceptance  is  evaluated. 

(4)  Current  mitigation  efforts  are  assessed. 

(5)  National  Environmental  Policy  Act  (NEPA)  and  Programmatic  Environmental,  Safety, 
and  Health  Evaluation  (PESHE)  requirements  are  incorporated. 

b.  ESOH  risks  and  corrective  actions  and  alternatives  are  developed  to  eliminate  or  reduce 
environmental,  health,  and  identified  hazards  and  unsafe  conditions;  and  the  threat  of 
regulatory  violations  is  identified. 

c.  Criteria  are  established  for  monitoring  and  reporting  of  pollution  elimination/reduction 
efforts. 

d.  A  containment  program  is  developed,  including  procedures  for  safe  use  and  disposal. 

e.  Handling  and  disposal  of  hazardous  material  are  included  in  life  cycle  cost  estimates. 
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3.2.9  Contamination 

NOTE:  Address  as  part  of  Project  Planning  Outputs  -6.3.1 .4 

a.  Requirements  for  contamination  control  are  identified  for  sensitive  components  or 
subsystems,  including: 

(1)  Need  for  normal,  medium,  or  challenging/stressing  contamination  control  to  meet 
requirements. 

(2)  Any  needs  for  new  or  upgraded  facilities. 

(3)  Shipping  and  prelaunch  operations. 

b.  Cleanliness  challenges  are  identified  and  solutions  proposed,  including: 

(1)  Uncleanable  materials. 

(2)  Solvent  incompatibility. 

(3)  Mission-unique  requirements  to  launch  vehicle. 

(4)  High  outgassing  materials. 

c.  Heritage  analysis  comprehensively  and  completely  demonstrates  that  prelaunch  cleanliness 
requirements  can  be  met  and  that  overall  end-of-life  (EOL)  requirements  can  be  met. 

3.2.10  Mass  Properties 

NOTE:  Address  as  part  of  Project  Planning  Outputs  -6.3.1 .4 

a.  Mass  properties  requirements  are  reviewed  and  generated;  changes  are  proposed  where 
applicable. 

b.  Baselined  design  is  reflected  in  the  mass  properties  analyses  and  reports. 

c.  Subsystem  and  subcontractor’s  definition  of  critical  mass  properties  parameters  are  reviewed 
and  tracked  to  ensure  that  specification  requirements  are  met. 

d.  Configuration  layout  for  optimizing  mass  properties  (weight,  balance,  and  inertia)  is 
analyzed. 

e.  Balance  weight  locations  are  defined.  Provisions  for  balance  weight  installation  are  ensured. 

f.  Test  plan  and  test  procedure  are  generated;  method  of  verifying  requirements  is  defined; 
required  mechanical  ground  support  equipment  (MGSE)  is  identified. 

3.2.11  Logistics 

NOTE:  Address  as  part  of  Project  Planning  Outputs  -6.3.1 .4 
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a.  Logistics  requirements  are  defined,  allocated,  baselined,  and  traced  to  system  requirements. 
Logistics  management  information  (LM1),  life  cycle  cost  (LCC)  analysis  with  a  discussion  of 
risks,  and  any  risk  reduction  or  control  are  included  for  the  following  logistics  areas: 

(1)  Design  interface  -  system  reliability,  maintainability,  availability,  survivability, 
including  hardness  and  unique  characteristics. 

(2)  Support  concepts/maintenance  plan  -  initial  and  steady-state  support;  implementation 
and  transition  schedule  at  organizational  and  depot  level;  warranties  and  SORAP. 

(3)  Manpower  and  personnel  -  operations,  maintenance  (hardware  and  software),  and 
training  support  personnel. 

(4)  Supply  support  -  support  concept  for  initial  and  steady  state,  sparing  requirement  to 
support  concept  of  operation. 

(5)  Support  equipment  and  simulators  -  common  and  specialized  organizational  and  depot 
support  equipment,  and  system-level  simulators  and  trainers. 

(6)  Training  and  training  support  -  initial  and  follow-on  training,  equipment, 
documentation  and  facilities;  student  requirements. 

(7)  Technical  data  -  engineering  drawings  and  technical  orders;  data  rights,  technical 
manual  contract/delivery  requirements. 

(8)  Computer  resource  support  -  software  and  database  maintenance,  facilities,  equipment, 
COTS,  and  documentation. 

(9)  Facilities  -  Space  projections,  new  or  reuse  requirements,  site  survey,  deployment 
transportable  facilities. 

(10)  Packaging,  handling,  storage  and  transportation  (PHS&T)  -  LMI  packaging  analysis, 
government  and  commercial  packaging  requirements,  and  packing  requirement  meet 
all  concept  of  operations,  including  deployment  storage,  oversized  and  special 
packaging  instruction,  and  air,  ground,  or  sea  shipping  requirements. 

3.2.12  Human  Systems  Integration  (HSI) 

NOTE:  Address  as  part  of  Project  Planning  Outputs  -6.3.1 .4 

NOTE:  This  section  presents  requirements  for  the  systems  engineering  planning  activities 
associated  with  human  systems  integration.  The  requirements  for  the  subordinate  domains  are 
contained  within  specific  domain-level  standards. 

3.2.12.1  Scope  and  Nature  of  Work 

a.  Human  systems  integration  (HSI)  shall  be  applied  as  part  of  the  overall  systems  engineering 
effort  to  efficiently  and  effectively  integrate  humans  into  the  design  of  the  system.  The  goals 
of  the  human  systems  integration  effort  shall  be  to: 
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(1)  Plan  and  execute  efficient  development  of  systems  that  effectively  integrates  human 
operators,  maintainers,  support  personnel,  and/or  users. 

(2)  Plan  for  impacts  of  military  system  operation,  use,  or  disposal  on  potentially  affected 
general  populations. 

(3)  Ensure  system  performance  by  ensuring  human  integration  and  specified  levels  of 
performance. 

(4)  Apply  to  all  aspects  of  military  systems,  equipment,  and  facilities  acquisition,  including 
analysis,  design,  development,  acquisition,  test  and  evaluation,  sustainment,  and  product 
improvement. 

(5)  Implement  by  making  effective  demands  upon,  and  tradeoffs  between,  personnel 
resources,  skills,  and  training  to  allow  for  knowledgeable  management  of  total  system 
ownership  costs. 

3.2.12.2  HSI  Planning 

a.  HSI  shall  be  part  of  the  overall  systems  engineering  effort  within  the  total  project  and  shall 
coordinate  with  all  appropriate  systems  engineering  specialties  or  disciplines. 4 

b.  HSI  planning  shall  establish  the  collaboration  between  HSI  domain  disciplines  with  emphasis 
on  each  domain  area’s  participation  in  system  (hardware  and  software)  design  and  testing. 

c.  HSI  shall  be  documented  and  managed  accordingly. 

d.  Risk  management  —  HSl-related  risks  and  issues  that  involve  technical,  cost,  or  schedule 
risks  shall  be  identified  and  managed  as  early  as  possible  as  part  of  a  program’s  overall  risk 
management  approach. 

e.  Reviews  —  HSl-related  activities  shall  be  reported  in  all  appropriate  programmatic  or 
technical  reviews. 

The  contractor  shall  establish  a  comprehensive  Human  Systems  Integration  (HSI)  effort  as 
part  of  the  overall  systems  engineering  effort. 

f.  HSI  shall  address  the  following  discipline  areas4 5: 

( 1 )  Manpower  -  number  and  mix  (military,  contractor,  and  civilian)  of  personnel  required, 
authorized,  and  available  to  train,  operate,  maintain,  and  support  the  system. 

(2)  Personnel  -  human  aptitudes,  skills,  experience  levels,  and  abilities  required  to  operate, 
maintain,  and  support  the  system  when  fielded  and  throughout  its  life  cycle. 


4  Support  material  for  HSI  planning  can  be  found  in  The  Aerospace  Corporation  report  TOR-2012(8960)-1  REV  A  -  HSI  Planning 
Requirements. 

5  Individual  DOD  services/components  may  organize  these  same  domain  areas  into  different  domain  area  combinations. 


(3)  Training  -  instruction  and  resources  required  to  provide  the  necessary  knowledge,  skills, 
and  abilities  to  properly  integrate,  operate,  maintain,  and  support  the  system. 

(4)  Human  factors  engineering  -  integration  of  human  capabilities  (cognitive,  physical, 
sensory,  and  team  dynamics)  into  system  design,  development,  modification,  and 
evaluation  to  optimize  human-machine  interactive  performance  for  operation  and 
maintenance  of  the  system. 

(5)  Environment  -  issues  related  to  water,  air,  and  land  and  the  interrelationships  between 
these  and  all  living  things. 

(6)  Safety  -  issues  including  design  of  operational  systems  to  minimize  the  possibilities  for 
accidents  or  mishaps  that  threaten  the  survival  of  the  system. 

(7)  Occupational  health  -  minimizing  risk  of  injury,  acute  and/or  chronic  illness,  disability, 
and/or  reduced  job  performance  to  personnel  who  operate,  maintain,  or  support  the 
system. 

(8)  Survivability  -  minimizing  risk  of  fratricide,  detection,  and  probability  of  being  attacked; 
and  inclusion  of  factors  that  enable  the  crew  to  withstand  man-made  or  natural  hostile 
environments  without  aborting  mission  or  suffering  acute/chronic  illness  or  death. 

(9)  Habitability  -  living  or  working  conditions  necessary  to  sustain  the  morale,  safety,  health, 
and  comfort  of  the  user/maintainer  population,  contributing  directly  to  personnel 
effectiveness  and  mission  accomplishment. 

g.  The  HS1  activities  shall  be  integrated  into  the  overall  systems  engineering  program  and 
management.  The  HS1  requirements  specified  herein  shall  be  coordinated  with,  but  shall  not 
duplicate,  efforts  performed  to  fulfill  other  contractual  program  tasks.  The  HSl-related  portion  of 
any  analysis,  design,  or  test  and  evaluation  program  shall  be  conducted  under  the  direct 
cognizance  of  a  qualified  HSl-domain  practitioner(s)  assigned  such  responsibility  by  the 
contractor.  “Qualified”  should  consider  basis  of  education,  experience,  and/or  certification  in 
systems  engineering,  human  systems  integration,  or  any  of  the  individual  HS1  domains. 

h.  The  contractor  shall  determine  the  scope  and  nature  of  HS1  domain  area  applicability  such  that: 

(1)  Program/contract  requirements  are  allocated  to  the  appropriate  HS1  domain  (discipline) 
areas. 

(2)  Responsible  entities  (e.g.,  HS1  Working  Group  and/or  Integrated  or  Cross  Product  Teams  - 
IPTs)  are  identified  for  each  applicable  HS1  domain  within  the  systems  engineering  1PT 
structure. 

(3)  Key  or  lead  HS1  personnel  in  all  applicable  domains  are  identified  and  described  in  terms 
of  qualifications. 

(4)  Interfaces  between  related  HS1  domains  are  defined  and  developed  to  ensure 
comprehensive  and  effective  execution  of  human-related  requirements. 

(5)  Interfaces  are  established  between  the  prime  contractor  and  all  subcontract  or  vendor  HS1 
activities. 
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(6)  Domain  interdependencies  and  tradeoffs  are  identified  to  ensure  humans  are  considered  as 
part  of  system  design  on  par  with  the  hardware  and  software. 

i.  HSI  planning  shall  be  described  in  a  configuration-managed  document  that  is  used  to  execute  the 

HS1  effort. 

j.  HSI  planning  shall: 

(1)  Include  the  human-related  tasks  to  be  performed,  milestones,  level  of  effort,  methods,  and 
design  concepts  to  be  used,  and  the  test  and  applicable  evaluation  methodologies. 

(2)  Describe  data  flow  between  HSI  domains  and/or  IPTs  (see  Appendix  B  Giver-Receiver 
relationships). 

(3)  Be  documented  as  a  human  systems  integration  plan  and/or  within  the  Systems  Engineering 
Management  Plan  (SEMP). 

(4)  Be  validated/updated  prior  to  major  programmatic  and  technical  reviews. 

(5)  Be  updated  at  program  rebaseline  and/or  engineering  change  proposal  (ECP). 

k.  The  following  activities  shall  be  considered: 

( 1 )  Integration  of  relevant  human-related  data  and  analyses  into  all  design  and  development 
activities  with  human-related  requirements,  design  features,  or  implications,  especially 
considering  the  relationships  between  these  efforts  and  opportunities  to  effect  efficiencies 
in  system  development,  operation,  and  maintenance. 

(2)  HSI  implications  for  integrated  development  of  logistics  and  operational  support  materials, 
including  procedures,  manuals,  and  technical  documentation. 

(3)  User  involvement  and  community  review  of  human-related  activities  and  products, 
including  prototype  assessments,  peer  reviews,  and  formal  reviews. 

(4)  Verification  and/or  validation  of  human  requirements  and  human-related  design 
options/solutions. 

l.  The  contractor  shall  identify  and  manage  human-related  risks,  issues,  and  opportunities  in  a  way 

that: 

(1)  Ensures  HSI-related  risks  are  managed  within  the  program’s  risk  management  process. 

(2)  Identifies  potential  cost,  schedule,  technical,  and  performance  risks  that  result  from  human 
system  integration. 

(3)  Quantifies  such  risks  and  their  impacts  on  cost,  schedule,  and  performance. 

(4)  Evaluates  and  defines  the  sensitivity  of  HSI-related  risks. 

(5)  Identifies  alternative  solutions  to  HSI-related  problems  and  defines  the  associated  risks  of 
each  alternative. 
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(6)  Documents  the  identified  risks,  their  potential  impact,  and  the  mitigation  action(s)  taken. 

(7)  Manages  the  actions  required  to  avoid,  minimize,  control,  or  accept  each  HSl-related  risk. 


m.  Human  systems  integration  domain  activities  shall  be  addressed  in  all  applicable  programmatic 
and  technical  reviews,  including  but  not  limited  to: 

(1)  Programmatic  reviews,  which  include  but  are  not  limited  to  program  management 
review,  integrated  baseline  review,  and  integrated  system  review. 

(2)  System  reviews,  which  include,  but  are  not  limited  to: 

i.  Concept  and  requirements  definition. 

ii.  Analysis  of  alternatives. 

iii.  System  requirements  review. 

iv.  Preliminary  design  review. 

v.  Critical  design  review. 

vi.  Test  readiness  reviews. 

vii.  System  safety  reviews. 

viii.  Engineering  change  proposal  reviews, 

ix.  Post-implementation  reviews. 

(3)  Subsystem  and  other  lower-level  reviews  including,  where  applicable,  software 
specification,  test  readiness,  and  functional  reviews  (e.g.,  support,  training,  systems  engineering, 
test,  and  manufacturing). 

3.2.13  System  Security  and  Information  Assurance 

NOTE:  Address  as  part  of  Project  Planning  Outputs  -6.3.1 .4 

a.  A  system  security  program  is  implemented  that  includes  Information  Systems  Security 
Engineering  (ISSE). 

b.  Protection  needs  are  documented,  including  identification  of  mission  assets  and  assessment  of 
threats  to  those  assets. 

c.  System  security  requirements  are  defined  and  complete.  Includes  system-specific  threats  and 
compliance  with  applicable  DOD,  national,  and  international  system  security  policies. 

Includes  system  security  design  constraints. 

d.  System  security  architecture  and  management  plan  is  documented. 

e.  Security  design,  including  constraints  and  tradeoffs,  is  detailed;  cryptography  plans  are 
coordinated  with  the  National  Security  Agency. 
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f.  Certification  and  accreditation  process  activities  are  coordinated. 

g.  Protection  mechanisms  have  been  verified  to  satisfy  security  requirements  and  residual 
security  risks  have  been  approved  by  the  appropriate  authorities. 

3.2.14  Reliability 

NOTE:  Address  as  part  of  Project  Planning  Outputs  -6.3.1 .4 

a.  Space  system-specific  reliability  requirements  are  defined,  allocated,  baselined,  and  traceable 
to  system  requirements. 

(1)  Parameters  and  limits  are  defined  at  this  level  and  provided  within  the  system 
specification. 

(2)  Reliability  requirements  are  reviewed  against  functional  requirements  and  customary 
design  practices. 

b.  Applicable  specific  design  tasks  and  analyses  are  conducted,  including: 

(1)  Failure  Reporting  Analysis,  Corrective  Action  System  (FRACAS). 

(2)  Source  selection  and  vendor  control  procedures. 

(3)  Failure  Modes  Effects  and  Criticality  Analysis  (FMECA). 

(4)  Derating  and  margins  of  safety. 

(5)  Fault  coverage. 

(6)  Single-point  failure. 

(7)  Redundancy/single  string. 

c.  The  reliability  program  plan  and  risk  management  plan  are  developed  for  final  top-level 
space  system. 

d.  Items  in  development  that  have  impact  on  support  resources  are  identified,  including  time, 
people,  money,  parts,  tools,  storage,  and  transportation  assets. 

3.2.15  Electromagnetic  Interference  and  Compatibility  (EMI/EMC) 

NOTE:  Address  as  part  of  Project  Planning  Outputs  -6.3.1 .4 

a.  EMPEMC  requirements  are  defined,  allocated,  baselined,  and  traced  to  system  requirements, 
including: 

(1)  Use  of  RF  shielded  enclosures  for  vehicle,  subsystems,  or  components,  and  other 
significant  design  features  affecting  EMC. 

(2)  Structure  RF  shielding  effectiveness  in  excess  of  40  dB. 
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(3)  Return  of  power  on  spacecraft  structure. 

(4)  Unshielded  or  untwisted  or  unpaired  wires. 

(5)  Radiated  emissions  requirements  less  than  20  dBuV/m. 

(6)  Gimbals  that  form  part  of  a  shielded  enclosure — high  risk. 

(7)  Radiated  susceptibility  requirements  in  excess  of  100  V/m — high  risk. 

(8)  Systems  having  passive  intermodulation  products  of  order  7  or  less  in  platform  receiver 
pass  bands. 

(9)  Any  EMC  wire  shields  or  grounds  that  are  required  to  flex  or  rotate  or  rub/roll  more 
than  20  times. 

(10)  Magnetic  dipole  requirements  more  stringent  than  3.5E-3  A-mA2/kg. 

(11)  All  first-flight/first-use  EMC  parts. 

(12)  All  cryo-cooled  sensor  EMC  designs. 

(13)  All  EMC  requirements  with  negative  margin. 

(14)  Any  RF  receiver  required  to  work  in  a  dense  EMI  environment. 

(15)  Any  RF  receiver  with  a  burnout  level  of  less  than  30  dBm  (1  mW). 

b.  A  summary  of  all  significant  areas  are  addressed  in  the  EMC  Control  Plan,  including  but  not 
limited  to  program  requirements  tailoring  and  the  use  of  heritage  equipment  and  other  ND1. 

c.  EMC  requirements  verification  planning  to  the  unit  level  is  conducted. 

d.  EMPEMC  risk  areas  are  identified  and  risk  mitigation  closure  plans  developed. 

3.2.16  System  Safety 

NOTE:  Address  as  part  of  Project  Planning  Outputs  -6.3.1 .4 

a.  System  safety  requirements  are  defined,  allocated,  baselined,  and  traced  to  system 
requirements,  including: 

(1)  System  safety  design  requirements  are  specified  and  safety  design  criteria  determined. 

(2)  Flazards  associated  with  the  system  are  identified  and  risks  involved  identified;  hazard 
analysis  is  complete. 

(3)  Risks  are  minimized  in  the  design,  materials,  testing,  and  production  of  end  item. 

(4)  Retrofit  actions  are  minimized  by  inclusion  of  safety  features  during  definition  and 
development  of  system. 
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(5)  Retrofit  actions  are  minimized  by  inclusion  of  safety  features  during  definition  and 
development  of  system. 

b.  Hazardous  substances,  components,  and  operations  are  isolated  from  other  activities,  areas, 
personnel,  and  incompatible  materials. 

c.  Catastrophic  risks  are  eliminated. 

d.  Critical  hazards  are  minimized. 


4.  Applicable  Documents 

The  following  documents  form  a  part  of  this  document  to  the  extent  specified  herein.  Unless  otherwise 
specified  the  issues  of  these  documents  are  those  cited  in  the  solicitation  or  contract. 

•  1SO-1EC-1EEE-15288:  2015,  Systems  and  Software  Engineering  —  System  life  cycle  processes. 

•  IEEE- 1 5288. 1 :  2015,  Standard  for  Application  of  Systems  Engineering  on  Defense  Programs. 

•  Shaw,  B  E,  Systems  Engineering  Requirements  and  Products,  Aerospace  Report  Number  TR- 
2013-00001.  The  Aerospace  Coiporation,  El  Segundo,  CA  (February  28,  2013). 

and 

SMC-S-001  (2013),  Systems  Engineering  Products  and  Requirements. 
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SMC  Standard  Improvement  Proposal 

INSTRUCTIONS 

1.  Complete  blocks  1  through  7.  All  blocks  must  be  completed. 

2.  Send  to  the  Preparing  Activity  specified  in  block  8. 

NOTE:  Do  not  use  this  form  to  request  copies  of  documents,  or  to  request  waivers,  or  clarification  of  requirements  on 
current  contracts.  Comments  submitted  on  this  form  do  not  constitute  or  imply  authorization  to  waive  any  portion  of 
the  referenced  document(s)  or  to  amend  contractual  requirements.  Comments  submitted  on  this  form  do  not 
constitute  a  commitment  by  the  Preparing  Activity  to  implement  the  suggestion;  the  Preparing  Authority  will 
coordinate  a  review  of  the  comment  and  provide  disposition  to  the  comment  submitter  specified  in  Block  6. 
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